A telecommunications network is made up of various intermediate entities through which signaling messages conveyed between a sending entity and a destination entity pass in transit. A signaling message contains information linked to a call from the sending entity to the destination entity, such as a call set-up request, together with other information, such as a notification of the presence of messages in a messaging system, for example.
These intermediate entities can have very varied roles, from routing the signaling message to actions to be effected on that message, such as inserting or removing certain information with a view to providing a particular service.
The Session Initiation Protocol (SIP) is defined by the Internet Engineering Task Force (IETF), initially with the objective of enabling setting up, modification, and termination of multimedia sessions in an IP network. The SIP has also been adopted by various standardization bodies and consortia, such as the 3rd Generation Partnership Project (3GPP) and Telecoms & Internet converged Services & protocols for Advanced Networks (TISPAN), in the framework of their definition of network control architectures based on IP transport. Those architectures include the IP Multimedia Subsystem (IMS) architecture. The vocation of the SIP is therefore to establish itself as the session set-up protocol used in operated public networks, whether mobile or fixed.
Compared to other signaling protocols, the SIP is characterized by its capacity to convey routing information in the SIP messages themselves. This is because the first request, which initiates a session and is called the initial request, can contain the addresses of the entities through which it has to pass. This data is entered into the initial request message by the sending entity that is the source of the session, having been recovered by the sending entity at the time of its registration in the network or via other mechanisms. The signaling path corresponding to the session is set up when the initial request is submitted, as a function of the destination of the call, the architecture of the network, and the services necessary for the session. Subsequent SIP requests and responses contain all the data necessary for routing them. This is a major difference compared to other protocols, for which routing is essentially based on tables present in the network entities and on the entities involved in the call storing routing data linked to the call.
There are two types of SIP message: requests and responses thereto. Responses take the reverse path to the associated request.
A distinction is made between initial requests and subsequent requests. Subsequent requests are part of the same SIP dialogue created by an initial request sent by a sending entity. Only some initial requests can create an SIP dialogue, for example the INVITE message. The path of subsequent requests, i.e. the set of SIP entities of the network through which all requests that are part of this dialogue must pass, is determined at the time of submitting the initial request creating the dialogue.
An SIP initial request message includes a “Request-URI” header (where URI stands for Uniform Resource Identifier) that contains the address of the destination entity of the request. A SIP request can optionally include a particular “Route” header that contains, in decreasing order and in the form of URIs, a list of the identities of the entities to be passed through before reaching the destination; these are the intermediate entities through which the request must pass.
An intermediate SIP entity, typically an SIP proxy, receiving an initial request proceeds to analyze it. If the request contains a “Route” header, the entity then considers the first SIP entity present in this header to be the entity to which it must forward the request. If not, it determines the next entity to which the request must be forwarded from the “Request-URI” header, using specific routing mechanisms.
Any SIP entity, whether it is an intermediate entity or not, can add a “Route” header or the URI of additional entities to an existing “Route” header. This function has many uses. For example, it enables the first entity of the network contacted to add to the “Route” header the identifier of the entity responsible for managing services allocated to the user of the entity sending the request, in order to guarantee that the request passes through that entity. The entities responsible for managing services are known as application servers (AS).
The intermediate SIP entities through which the initial request passes that wish to remain in the signaling path insert their identifiers into a “Record-Route” header of the initial request before forwarding it to the next node.
The identifiers present in the “Record-Route” header at the time of submitting the initial request are repeated in the “Route” header of subsequent requests. These requests are routed in the following manner. An intermediate SIP entity receiving a subsequent SIP request proceeds to analyze it. If the request contains a “Route” header, then this entity considers the first SIP entity present in this header to be the entity to which it must forward the request. If not, it considers the entity present in the “Request-URI” header as the entity to which it must forward the request.
At the time of submitting an SIP request, each entity that is passed through adds its address to a “Via” header. Accordingly, this header accumulates in order the addresses of all the SIP entities passed through, including the address of the entity sending the request.
When an entity, which may be the destination entity of the request or an intermediate entity, generates a response to a request, it inserts therein a “Via” header containing the addresses received in the “Via” field of the request, in the same order. Each entity receiving this request, if it decides to forward it to the next node, sends it to the address that is first in the “Via” header of this response.
Generally speaking, it can happen that intermediate entities are not accessible at a given time, for example in the event of an equipment failure or overload. In such circumstances, the network can behave in two ways: either a message that should pass in transit through any such entity is rejected or an alternative path is found to enable the message to be conveyed to its destination anyway. This behavior can depend in particular on the characteristics of the entity concerned, namely whether it is indispensable or not, and on the signaling message type.
The SIP generally does not offer this alternative and allows only the first solution, i.e. rejection of the message.
Thus when an intermediate entity determines that the first SIP entity in the “Route” header of a request is not accessible, it can then send a failure response to the sending entity, even if it would have been preferable to convey the request to its destination avoiding this inaccessible intermediate entity, and even if it is unable to benefit from the processing operations that it could have effected.
Similarly, if an intermediate entity decides to send an SIP response to the next node and the SIP entity whose address is the first in the “Via” header of that response is not accessible, then it stops sending that response and can even cancel the transaction corresponding to that response, even if it would have been preferable to convey this response to the destination avoiding the inaccessible intermediate entity.